In ROHC (Robust Header Compression) put forward by RFC3095 protocol, header compression is described as the interaction between two state machines (compression and decompression state machine). Compression gain is obtained through establishing context at both ends of the link, namely a set of static and dynamic header fields. Context must be synchronized during operation of compression and decompressor. ROHC adds CRC (Cyclic Redundancy Check) in compression packet and ensures context is updated timely and correctly through feeding back ACK/NACK (Acknowledgement/Negative Acknowledgement).
Compressor is in one of the three statuses: IR (Initialize Refresh) status, FO (First Order) status and SO (Second Order) status, which represents the degree of available header compression.
Decompressor is also in one of the three statuses: NC (No Context), SC (Static Context) and FC (Full Context) status, which represents the ability of decompressor to decompress corresponding data packet header, thus the status corresponds to the performance of header compression. Mutual transition can be conducted among statuses.
ROHC supports three operation modes: U (unidirectional) mode, O (bi-directional optimization) mode and R (bi-directional reliable) mode. Inter-conversion can be conducted among the three modes. Each mode stipulates the methods and frequency of information interaction, for example, whether feedback is widely used. If reliable mode is converted timely, more feedback information such as status, special field, etc. will be interacted to ensure consistence of receiver and sender's context as much as possible, thus improving the probability of correct decompression in high compression ratio status.
When RFC3095 protocol stipulates that CRC of decompressor is conducted successfully, ACK is fed back if it refers to updated packet, namely IR/DYN package at present. Compression and decompressor work in U mode initially. Decompressor will be in O or R mode and feed back ACK to compressor after it successfully decompresses an updated packet, thus triggering compressor to be converted into O or R mode. Later the two ends will work in O or R mode. If decompressor continuously detects successful CRC, status transition from NC, SC to FC will be conducted and ACK (O mode) will be fed back to convert R mode to O mode. If decompressor continuously detects CRC failure, the status will be degraded by converting O mode to R mode and NACK (R mode) will be fed back. According to feedback information, compressor operates corresponding actions to coordinate the synchronization of context status.
After LTE-A (Long Term Evolution Advanced) system introduces Relay, network architecture diagram is determined preliminarily as shown in FIG. 1. The node includes:
Donor-eNB (Donor Evolved Node B, DeNB): eNB wirelessly connected to RN;
Relay-Node (Relay node, RN): the entity between DeNB and UE (User Equipment);
Relay-UE (R-UE): UE which performs data interaction with RN, and it can be LTE UE;
Macro UE: UE which performs direct data interaction with DeNB, and it has nothing to do with RN.
The interface includes:
Un interface: the interface between RN and DeNB
Uu interface: the interface between UE and RN
Such network architecture makes user data transmitted at Un interface have complex head construction with nesting IP (Internet Protocol) and GTP (GPRS Tunnelling Protocol, GPRS: General Packet Radio Service) as shown in FIG. 2, which is a diagram of data packet structure of VoIP (Voice over Internet Protocol) at Un interface. Explanation is given below by taking voice service as the example:
Outer IP/UDP (User Datagram Protocol) header corresponds to IP address carrying RN, GTP header carries UE-related service-bearing tunnel information, and inner IP/UDP/RTP (Real-time Transport Protocol) corresponds to IP address and service information of UE. For outer and inner IP, headers such as UDP and RTP can be compressed with existing compression profiles in PDCP (Packet Data Convergence Protocol).
In the present PDCP, the format and information of PDU (Packet Data Unit) transmitting compression feedback are shown in FIG. 3.
Herein, the meaning of field information value in D/C field and PDU Type field is shown in FIGS. 1 and 2 respectively.
TABLE 1Meaning of Field Information Value in D/C FieldBitDescription0Control PDU1Data PDU
TABLE 2Meaning of Field Information Value in PDU Type FieldBitDescription000PDCP status report001Interspersed ROHC feedback packet010-111Reserved
In course of implementing the present invention, the inventor finds out there are at least the problems below in the present technology:
There is no scheme for the whole IP/UDP+GTP+IP/UDP/RTP header compression in the present compression profiles, which can only process outer IP header (such as IP/UDP or IP/TCP) and inner IP header (such as IP/UDP/RTP or IP/TCP), without including GTP.
In the present PDCP, only one ROHC feedback format is supported. That is to say the feedback of outer and inner header can not be effectively differentiated with the scheme for respective compression of outer and inner IP header, thus compression profiles cannot be correctly implemented, which greatly affects compression efficiency.